home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text0540.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  3.5 KB  |  77 lines
  1. Dave Raggett raised some interesting issues in his message. In
  2. particular:
  3.  
  4. > Caching
  5. >-------
  6. >
  7. > It will be desirable to avoid overloading servers with popular documents by
  8. > supporting a caching scheme at local servers (or even at browsers?). This
  9.           As well as caching, replication would be nice. But this is
  10.       only practical if resource identifiers do not contain location
  11.       information (otherwise replication is only possible by making
  12.       all the peer servers to appear to be one machine, as in the
  13.       DNS CNAME suggestion I made some time ago).
  14.           But if resource identifiers do not contain host information
  15.       then you need an external means of determining how to reach
  16.       the resource. This is analagous to routing protocols (an address
  17.       is not a route ...)
  18.           Such a system is probably over ambitious for now. Anyway,
  19.       back to caching ...
  20.  
  21. > Servers need to be able to work out what documents to trash from
  22. > their caches.
  23. > A simple approach is to compare the date the document was received with the
  24. > date it was originally created or last modified. Say it works out that when
  25. > you got the document it was already one week old. 
  26. > Then one rough rule of thumb
  27. > is to trash it after another week. You can be rather smarter if there is a
  28. > valid expiry date included with the document:
  29.  
  30.           I think this is silly. I haven't changed a document for
  31.       six months, therefore it is safe to say that it won't be
  32.       changed for the next six months ...
  33.           This also depends on hosts agreeing on the date. To quote
  34.       RFC1128, talking about a 1988 survey of the time/date on
  35.       Internet hosts, "... a few had errors as much as two years"
  36.  
  37. > I think that we need to provide an operation in which the server returns a
  38. > document only if it is later that a date/time supplied with  the request. 
  39.  
  40.           This would be useful as part of a replication system,
  41.        as long as both ends exchanged timestamps initially so
  42.        that the dates can be synchronised.
  43.  
  44. > Note that servers shouln't cache documents with restricted readership since
  45. > each server don't know the restrictions to apply. This requires a further
  46. > header to identify such documents as being unsuitable for general caching:
  47.  
  48. and also ...
  49.  
  50. > What happens if a copyright protected document is saved in the cache of a
  51. > local server? We have got to ensure that the rightful owners get paid for
  52. > access even when the document is obtained from a local server's cache.
  53.  
  54.          It may be stating the obvious, but once you allow a
  55.     user to access you data such that they can save it, there is
  56.     no technical way you can prevent them from publically
  57.     redistributing your data. This is a social/legal problem,
  58.     not a technical one.
  59.          Accepting that nothing can be done to stop deliberate
  60.     abuse of licensed information, there is a need to prevent
  61.     accidental abuse. Probably the simplest way to do this is
  62.     to mark the document as one which should NOT be cached.
  63.           
  64.          Perhaps this leading towards a very simple minded
  65.     caching scheme a la DNS, where information is returned
  66.     together with an indication of its "time to live" (TTL),
  67.     ie how long this can reasonably be cached. Setting a default
  68.     TTL for a server gives an idea of the "volatility" of the
  69.     information contained therein 
  70.          Unless a document is exported with world read access,
  71.     it should always have TTL of 0.
  72.  
  73.  
  74. Kevin Hoadley, Rutherford Appleton Laboratory, khoadley@directory.rl.ac.uk
  75.                
  76.  
  77.